Subject: Ongoing projects - status update as of 2024/03/06 / requests for clarification
From: "Michal Siemaszko" <[email-masked]>
To: Jürgen Albert <[email-masked]>, "Mark Hoffmann" <[email-masked]>
Date: Wed, 06 Mar 2024 03:52:15 +0100

Hi,

Status update as of 2024/06/06 is the following:

Smart City

Gecko EMF Persistence for OSGi

I started working on "Implement Multidimensional Arrays Support in DBObjecBuilder and EObjectBuilder #25" (https://github.com/geckoprojects-org/org.gecko.emf.persistence/issues/25), which you mentioned in https://github.com/de-jena/ogc-features/pull/1#issuecomment-1973787966.

Two questions I have pertaining to this are:

 • Should this be billed under “SmartCity 01” in Toggle ?

 • Please confirm regarding starting branch to be used -- new branch (`issue25-multidimensional-arrays-support`) was created off `snapshot` branch ( https://github.com/geckoprojects-org/org.gecko.emf.persistence/tree/snapshot ) as that is where I found most recent commits;

OGC Features

In PR https://github.com/de-jena/ogc-features/pull/1 I shared a week ago, I mentioned two (2) issues (“Problems / Issues” section of https://github.com/de-jena/ogc-features/pull/1#issue-2157939344) and asked five (5) questions (“Questions / Next steps” section of https://github.com/de-jena/ogc-features/pull/1#issue-2157939344).

All (2) issues were addressed, however not all questions were, therefore I’d like to ask for clarification:

 1. _*Should "GeoJSON" model be linked with and "contained" by "OGC API Features" model ?*_

You have not replied to this question it seems. Please clarify.

 1. _*Can query consist of columns for both container and contained ?*_

You have not replied to this question it seems; perhaps https://github.com/de-jena/ogc-features/pull/1#issuecomment-1978346883 refers to this, but it quotes a different question, plus it is not clear what you mean. Please clarify.

 2. _*Does Gecko EMF Push Stream Provider (EPushStreamProvider) support creating push streams for contained collections ?*_

You replied via https://github.com/de-jena/ogc-features/pull/1#issuecomment-1978389100. Yes, your assumption here is correct, i.e. I need to use EMF Push Stream Provider to index `Feature` Eobjects which are contained by `FeatureCollection`. I already tried the "flatMap" approach and got compilation errors, hence my question; I will try again, perhaps I overlooked something.

 3. _*Which sub-sets of "Common Query Language" (CQL2) should be implemented ?*_

You have not replied to this question it seems; we also discussed this during our call on 2024/02/21, when you mentioned you will ask Stefan. Please clarify.

 4. _*Should SOAP API, in addition to already implemented REST API, be implemented now or after "Part 3: CQL" is ready ?*_

You replied “No”, however, this is a two-part question -- i.e. “now” OR “after CQL is ready”. Please clarify.

Also: what does comment https://github.com/de-jena/ogc-features/pull/1#issuecomment-1978346883 refer to ?

AVATAR

Mark, reporting issues, along with working solutions, along with asking questions, is part of work I do.

Please clarify regarding the following:

 1. 

   • I found one open issue in https://github.com/DataInMotion/avatar-libraries repository (“Open HL7 Features for spec compliancy #9” https://github.com/DataInMotion/avatar-libraries/issues/9), which implies items outlined there should be implemented;

   • However, Mark’s comment (https://github.com/DataInMotion/avatar-libraries/issues/17#issuecomment-1961454208) in reply to my question “*Considering all these issues and time needed to fix those, should a fully compliant backend using "HAPI FHIR – Java API for HL7 FHIR Clients and Servers" (https://github.com/hapifhir/hapi-fhir) be set up then? Perhaps it could be run in a docker container, like the consent management solution suggested (https://www.ths-greifswald.de/en/researchers-general-public/gics/) and the two integrated; The trade-off would be using different tech stack – i.e. what "HAPI FHIR" is using*” _*appears contradictory*_ to having https://github.com/DataInMotion/avatar-libraries/issues/9 still open;

   • i.e. in https://github.com/DataInMotion/avatar-libraries/issues/17#issuecomment-1961454208 Mark wrote: (…) *Navimatix/Fraunhofer AST will create a initial fhir server setup from https://github.com/hapifhir/hapi-fhir. So not our task anymore* (…);

   • Does that mean entire “Avatar Libraries” project ( https://github.com/DataInMotion/avatar-libraries ) should is not to be worked on anymore ?

   • I would have started with https://github.com/hapifhir/hapi-fhir was it not for the technology stack imposed for this project by Mark in https://github.com/DataInMotion/avatar-libraries/issues/1

 1. What about the other AVATAR project ("HIMSA") we discussed during our meeting in Jena ? Was https://github.com/DataInMotion/avatar-dataspaces created for this purpose ?

 2. What about connecting those to consent management system via "gICS" project (https://www.ths-greifswald.de/en/researchers-general-public/gics/) ?

 3. Please clarify your statement “*You are lost in discussions about if you are right and if you did something wrong*”, as it appears you have not read technical documentation I provided as part of PR containing working solution, made multiple contradictory / illogical statements regarding root cause of *issues which I reported as is required of my work*, and insisted on such, instead of calming down, re-reading what was provided in writing and as part of that PR, which, again, was a working solution, and clarifying / supplementing information I asked, as, again is part of work I do.

Regards
-- 
  Michal H. Siemaszko
  Email: [email-masked]
  WWW: http://ideas.into.software/
  LinkedIn: http://www.linkedin.com/in/mhsiemaszko/